NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/14434

Internet Message Format | 1996-08-05 | 7.8 KB

Path: gmrc.gecm.com!newsmasters
From: [e-mail] (Paul Johnson)
Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk,comp.object
Subject: Re: OO language tools
Date: 28 Mar 1996 11:56:57 GMT
Organization: GEC-Marconi Research Centre
Message-ID: <4jduq9$[e-mail]>
References: <4j4uau$[e-mail]>
NNTP-Posting-Host: polonius.gmrc.gecm.com
X-Newsreader: WinVN 0.99.7

In article <4j4uau$[e-mail]>, [e-mail] says...

>We are researching what tool sets are availible commercially for
>developing embedded real-time software in the popular OO languages like C++,
>Smalltalk, Eiffel etc.

I've been evaluating ISE Eiffel 3.3.4.  Here are some initial results.

I used a Pentium 90 machine with 16Mb running Windows 95.  Eiffelbench
was supplied on a CD-ROM for Windows 3.1.

Startup is a trifle clumsy.  You have to select a project, or start a
new one.  A "project" is held in a directory (which must exist before
you start), and Eiffelbench then creates a subdirectory for its datafiles.
This makes it a little difficult to identify the right directory unless
you know what you are doing.  A suffix-based filename system would work
better here, because Windows users will know what to expect.  Once you
have found the right directory, everything works OK.

The browser has some excellent facilities.  Once you are up and running,
you can view the system as an ACE file or a list of classes organised
alphabetically or by cluster.  If you click on a class name and drag it
to the class button, up pops a window with the class text.  Click a button
at the bottom of this window, and you can get the short, flat, or
short-flat forms.  All of these contain clickable class and feature names,
allowing you to wander around your system finding out what is happening.
Class texts in any form can also be exported in various formats to
produce printed documents, complete with bold keywords and italic comments.

Some of the longer operations carry warnings about how long it will take,
but these are applied a little inconsistantly.  For instance I usually
switched the "system" window from displaying the ACE file to displaying
a list of clusters and classes (which can then be opened via the browser).
This conversion only took a few seconds, but still carried a warning.
On the other hand, switching from class text to short-flat view might take
several minutes but carried no warning.  Overall there seemed to be some
rough edges in the design of the user interface.

It was not clear how I could create the first class.  I called up the
template
ACE file, and declared a new cluster in it.  Then I clicked on the "Class"
tool and typed in the name of the class.  The system asked what cluster,
but would not accept the name I entered.  I eventually had to resort to an
outside text editor.  Once a ".e" file existed, Eiffelbench accepted that
the cluster was real, and allowed me to create other files there.

The browser and its different views of the system are only available after
you have compiled the system.  This creates a catch-22 situation, because
errors and inconsistencies can stop you from compiling, and the lack of
browser facilities makes it much harder to track down the problem.  It
would be nice if the compilation could continue in spite of errors in
some classes.  Then library classes would be browsable even if their
erroneous clients are not.  There was no indication as to whether the
browser facilities were available (e.g. grayed-out buttons).  They simply
stopped working until the compilation had succeeded.

The "melting ice" technology worked well.  Turnaround was fast even on
complex systems.  The interpreted side of the system could keep up with
the demands of testing.  I haven't got a C compiler, so I can't comment
on the compiled code.

I used an early version of the graphics classes to do some animation.
This was not a fair test because I had no manual and was trying to do
something moderately unusual.  The classes seemed a bit slap-dash in their
design, but generally functioned OK.  I gather that ISE have since improved
this side of the product considerably.

Reliability was disappointing (although I have seen worse in other
commercial tools).  The browser crashed unpredictably when I navigated
from one class to another, and sometimes the browser's "hot spots" got
out of synch with the class text.  Given Eiffel's support for correct and
reliable software, I expected better.  However I was running a Windows 3.1
version on Windows 95, and I gather that ISE have improved the reliability
since version 3.3.4.

I don't like the design of the data structure libraries.  The phrase
"kitchen sink" springs to mind.  Inheritance was used inappropriately, and
in one case I had to turn off assertion checking for the classes because a
descendant violated an ancestors invariants.  This suggests poor review of
designs and lack of thorough testing.

ISE Eiffel is not a complete solution for software engineering.  You need
to integrate your own configuration control and library release systems.
This is important.  (Note that SCCS uses "%" characters to tag version
control fields in program text, which conflicts with Eiffel's use of them
as escape characters for string literals.)  Eiffelbench does include an
option for "precompiling" libraries to reduce the time and space required
for their client applications during development.

Debugger facilities were rather limited.  You can put breakpoints on
routines, but not lines.  Tracing facilities were similarly limited.
If an error occured then a stack trace was generated, but it only told
you what routine had failed, and what call was being made at the time.
If you called the same routine in several places this was was less than
useful.  There was no access to local variables from the debugger, and
so the only way to figure out what was happening was to insert "debug"
statements (which are supported by the language) into the faulty routine.
This should not be necessary.  The debugger should include access to local
variables, and it should know about source-code line numbers.  Ideally I
should be able to drag a stack frame to the class button, and be shown
the offending section of code.  Access to object attributes was good: you
could drag an object ID onto the object button and be shown its state.
Objects could then be browsed in a similar way to classes.

It would be nice if classes could generate their own version of their
state for the debugger, as well as having the raw attribute value list
available.  If I suspect that one of my routines has put the wrong value
in a list then I want to see the contents of the list in one window (like
an array) rather than having to navigate its private pointer structure
manually.  Something like the "ascii" feature in ANY could be called to
generate this (although something would have to be done about handling
reference values).  It would also be useful to be able to call features
from within the debugger.

On the other hand, the Eiffel assertion facilities count for a lot.  At
least bugs were caught at their source, rather than later in the program.
But once I had the offending routine code (isolated by an exception
violation), actually locating the bug sometimes proved rather hard.

Overall I would be happy to take ISE Eiffel on board for small to medium
projects.  It might be fine for a large project as well, but I haven't
got the experience to comment on that.  However the Rainbow project seems
very happy with it.

Paul.

--
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
[phone]         +-----------+-----------------------------------------+
Work: <[e-mail]>       | You are lost in a twisty maze of little
Home: <[e-mail]>    | standards, all different.